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DETAILED ACTION 

Continued Examination Under 37 CFR 1.114 

1 . A request for continued examination under 37 CFR 1.114, including the fee set 
forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this 
application is eligible for continued examination under 37 CFR 1.114, and the fee set 
forth in 37 CFR 1 .17(e) has been timely paid, the finality of the previous Office action 
has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 
5/08/2008 has been entered. 

Claim Rejections - 35 USC § 103 

2. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

This application currently names joint inventors. In considering patentability of 
the claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of 
the various claims was commonly owned at the time any inventions covered therein 
were made absent any evidence to the contrary. Applicant is advised of the obligation 
under 37 CFR 1 .56 to point out the inventor and invention dates of each claim that was 
not commonly owned at the time a later invention was made in order for the examiner to 
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consider the applicability of 35 U.S.C. 103(c) and potential 35 U.S.C. 102(e), (f) or (g) 
prior art under 35 U.S.C. 103(a). 



Claims 1, 3, 5-8, 10, 12-14, 16, 18-20, 22, 24-25 and 28-29 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Ludwig et al. (Ludwig hereinafter) (U.S. PG 
Pub No. 2003/0004874) in view of Falk et al. (Falk hereinafter) (U. S. PG Pub No. 
2004/01 1 1302) further in view of Haseltine et al. (Haseltine hereinafter) (U. S. Patent 
No. 6,578,015). 



With respect to claim 1 , Ludwig teaches "A computer readable storage 
medium for storing an electronic data record, of an invoice, the electronic data 
record comprising" as the system may allow data to be entered for the following 
exemplary fields, which the system may be adapted to store as global information on 
the database: name, address, city, state, zip, country, phone, number, fax number, and 
maximum invoice amount allowed. The system may use the maximum invoice amount 
allowed field to establish a threshold for a maximum payment for a single invoice 
(Ludwig Paragraph 0075). 

"a data field for identification of a current state of the processing of the 
invoice wherein the current state is assigned by a user through a dialogue 
displayed on a display device" as "Paid Through Another Source" may be provided 
by the system as an option for the biller system user to mark an invoice as closed by 
selecting desired invoices and clicking on the "Paid through another source" button. 
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Once this occurs, the system may, for the invoices in question, update their audit trail to 
reflect that they were paid outside the system, and then change their status to closed 
(Ludwig Paragraph 0091 & 0130). Therefore the user is entering the current state 
"closed" by clicking on the button. Therefore the identification of the current invoice is 
that it is paid and closed. 

Further Ludwig teaches the filter area, the system may provide the following 
exemplary choices: by date (past due, eligible for discount, due within xxx days); and by 
status (paid invoices, adjusted invoices, unpaid invoices, paid through another source); 
and by payer (all payer, specific payer); and by attribute range between xxx and yyy 
(none, invoice numbers, store/location, purchase orders, purchase request number, 
invoice issue dates, dollar amount, bill of lading numbers, receiving location zipcodes, 
invoice aging) (Ludwig Paragraph 0080). These lines also teach the identification of 
the current state of the processing of the invoice. 

"the data field is used for starting a workflow which depends on the current 
state" as (Ludwig Figures 6a-6c and 9a-9b). Figures 9a-9b teach a state dependent 
workflow for the payment of an invoice. Figure 7c teaches a state dependent workflow 
for adjustment of invoices. 

In figures 9a and 9b, the workflow for the payment is being initiated which is 
being dependent on the current state of the invoice, which is that the invoice is pending 
or due. 

"wherein the data field has a link to the current state stored in a table" as 

the system may link the status field to the invoice history page, at which the system may 
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display a full status history for the selected invoice. By default, the system may display 
the following exemplary columns: payer name, invoice number, due date, status, net 
amount due, amount to pay, P.O. number, P.O. requisition number, store number, and 
select (Ludwig Paragraph 0092). Therefore, these lines teach that the status field is 
being linked to the history page which contains the current status of an invoice. 

"a plurality of states of the processing of the invoice" as the perspective of 
the payer system user, the system may identify an invoice as having one of the 
following exemplary states: presented, viewed (an invoice may be considered "viewed" 
when a invoice display query is built with the invoice included; the user does not 
necessarily need to actually see the invoice to have it considered viewed), verified (an 
invoice that is in this state may be rolled back to viewed given the user has the 
permission to verify), payment initiated, payment authorized, payment pending (an 
invoice in this state may be rolled back to verified given the user has the permission to 
authorize payment), paid, and closed (Ludwig Paragraph 0127). 

"an instruction which depend on the current state and are automatically 
executable by a computer system" as (Ludwig Paragraph 0091 and 0045). In 
paragraph 0045 email notices are being sent automatically based on the current state of 
the invoice. 

Ludwig teaches the elements of claim 1 as noted above but does not explicitly 
discloses, "the current state stored in a state value table comprising a plurality of 
states of the processing of the invoice, and the state value table comprises an 
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instruction which depend on the current state and are automatically executable 
by a computer system." 

However, Falk discloses, "the state value table comprises an instruction 
which depend on the current state and are automatically executable by a 
computer system," as the main purposes of the workflow table is to allow the system 
to determine the next workflow state for a transactional folder based on its current state 
and the completion of a given application function that alters that folder-i.e., the 
workflow state transition (Falk Paragraph 0589 and Figure 24). In addition to defining 
workflow state transitions, the workflow table implicitly defines workflow navigation as 
well. For any given transactional folder in a given state, the workflow table will define 
the application functions that are allowed to be performed in this state (Falk Paragraph 
0591 ). Workflow state transitions are simple and deterministic-the next workflow state 
is determined simply by the current workflow state and the application function that was 
completed. However, in some cases, the transition can only be determined by 
inspecting other data elements within the transactional folder (Falk Paragraph 0603). 
Examiner interprets the workflow table as state value table comprising the current state. 
Workflow table/state value table further comprises executable functions that are allowed 
to be performed based on the current state. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teaching of the cited references because Falk's 
teaching would have allowed Ludwig to provide an automated system with the following 
capabilities unique to inter-organizational business transaction processing: 1) a 
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centralized network hub (web-based) that facilitates the inter-connection of various 
organizations and eliminates the proliferation of point-to-point interfaces, 2) an inter- 
organizational workflow management system that provides a common framework for 
managing the state and status of all transactions within the system, 3) an inter- 
organizational transaction processing component that supports multiple organizations 
and their distinct relationship with each transaction while also ensuring the security and 
privacy of each organization's data, 4) a unified data model mechanism that allows 
common data elements to be exchanged while also supporting organization specific 
interface requirements, and 5) application specific data and functionality specific to the 
types of business transactions being processed. 

Ludwig and Falk teach elements of claim 1 as noted above but do not explicitly 
teach "the current state stored in a state value table comprising a plurality of 
states of the processing of the invoice." 

However, Haseltine discloses "the current state stored in a state value table 
comprising a plurality of states of the processing of the invoice" as a status table 
may be generated for the bill to indicate the current status of the bill (Haseltine Col 3, 
Lines 41-43). Status tables 436 may also maintained in the active area 430 and may be 
viewed by customers. As the name implies, the status tables 436 track the status of the 
bills presented to the customers in the active area 430. For example, the status tables 
436 may track whether a customer's bills have been viewed, paid, have been submitted 
or are pending. Other indicia indicative of the status of the customers' bills may also be 
included in the status tables 436 (Haseltine Col 6, Lines 1 1-20 and figure 4). The table 
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shows the current status of the invoice/bill and status table 436 shown in figure 4 shows 
plurality of processing states as well. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teaching of the cited references because 
Haseltine's teaching would have allowed Ludwig to allow customers to view and pay 
electronic bills in a flexible manner without the involvement of paper bill and checks. 

With respect to claim 3, Ludwig teaches "the computer readable storage 
medium for storing electronic data record of claim 1, wherein the state value table 
comprises a description of the current state" as the system may link the status field 
to the invoice history page, at which the system may display a full status history for the 
selected invoice. By default, the system may display the following exemplary columns: 
payer name, invoice number, due date, status, net amount due, amount to pay, P.O. 
number, P.O. requisition number, store number, and select (Ludwig Paragraph 0092). 

Ludwig teaches the elements of claim 3 as noted above but does not explicitly 
discloses, "wherein the state value table comprises a description of the current 
state." 

However, Haseltine discloses, "wherein the state value table comprises a 
description of the current state" as a status table may be generated for the bill to 
indicate the current status of the bill (Haseltine Col 3, Lines 41-43). 
Status tables 436 may also maintained in the active area 430 and may be viewed by 
customers. As the name implies, the status tables 436 track the status of the bills 
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presented to the customers in the active area 430. For example, the status tables 436 
may track whether a customer's bills have been viewed, paid, have been submitted or 
are pending. Other indicia indicative of the status of the customers' bills may also be 
included in the status tables 436 (Haseltine Col 6, Lines 11-20). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teaching of the cited references because 
Haseltine's teaching would have allowed Ludwig and Falk to allow customers to view 
and pay electronic bills in a flexible manner without the involvement of paper bill and 
checks. 

With respect to claim 5, Ludwig teaches "the computer readable storage 
medium for storing electronic data record of claim 1, wherein the state value table 
comprises an assignment of the current state to an event which can occur during 
the processing of the invoice" as in this section, the system may permit biller system 
users to be associated with specific system events, which associations the system may 
be adapted to store as global information on the database. Any time one of these 
specific events occurs, the system may generate an automatic e-mail and send it to the 
selected list of biller system users. For example, exemplary distribution list choices may 
include: invoices loaded successfully, invoices loaded unsuccessfully, invoice adjusted, 
payment authorized, payment canceled, payment completed, and payment notification 
(Ludwig Paragraph 0104). The system may only permit invoices with the status of 
"paid", "presented", or "viewed" to be closed. All other invoice states may indicate payer 
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workflow is in progress, and the system may not permit invoices having such states to 
be closed (Ludwig Paragraph 0105). 

Ludwig teaches the elements of claim 5 as noted above but does not explicitly 
discloses, "the state value table comprises an assignment of the current state." 

However, Haseltine discloses, "the state value table comprises an 
assignment of the current state" as a status table may be generated for the bill to 
indicate the current status of the bill (Haseltine Col 3, Lines 41-43). Status tables 436 
may also maintained in the active area 430 and may be viewed by customers. As the 
name implies, the status tables 436 track the status of the bills presented to the 
customers in the active area 430. For example, the status tables 436 may track 
whether a customer's bills have been viewed, paid, have been submitted or are 
pending. Other indicia indicative of the status of the customers' bills may also be 
included in the status tables 436 (Haseltine Col 6, Lines 11-20). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teaching of the cited references because 
Haseltine's teaching would have allowed Ludwig and Falk to allow customers to view 
and pay electronic bills in a flexible manner without the involvement of paper bill and 
checks. 

With respect to claim 6, Ludwig teaches "the computer readable storage 
medium for storing electronic data record of claim 1, wherein the electronic data 
record is at least partially accessible via the Internet and wherein the content of 
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the data field for the current state or a data field for comments is editable via the 
Internet" as the system may permit information to be maintained and edited at this 
page, which the system may store as global information on the database (Ludwig 
Paragraph 0064). The present invention may be appropriately adapted to include such 
communication functionality and Internet browsing ability (Ludwig Paragraph 0157). 

With respect to claim 7, Ludwig teaches "the computer readable storage 
medium for storing electronic data record of claim 1, wherein the state value table 
comprises one or more state dependent proposals for changing the current 
state" as the system may, for the invoices in question, update their audit trail to reflect 
that they were paid outside the system, and then change their status to "Closed" 
(Ludwig Paragraph 0091 & Figure 9a). Figure 9a shows invoice status list reference 
numeral 909. 

Ludwig teaches the elements of claim 7 as noted above but does not explicitly 
discloses, "the state value table." 

However, Falk discloses, "the state value table" as the main purposes of the 
workflow table is to allow the system to determine the next workflow state for a 
transactional folder based on its current state and the completion of a given application 
function that alters that folder-i.e., the workflow state transition (Falk Paragraph 0589 
and Figure 24). Examiner interprets the workflow table as state value table comprising 
the current state. 
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It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teaching of the cited references because Falk's 
teaching would have allowed Ludwig to provide an automated system with the following 
capabilities unique to inter-organizational business transaction processing: 1) a 
centralized network hub (web-based) that facilitates the inter-connection of various 
organizations and eliminates the proliferation of point-to-point interfaces, 2) an inter- 
organizational workflow management system that provides a common framework for 
managing the state and status of all transactions within the system, 3) an inter- 
organizational transaction processing component that supports multiple organizations 
and their distinct relationship with each transaction while also ensuring the security and 
privacy of each organization's data, 4) a unified data model mechanism that allows 
common data elements to be exchanged while also supporting organization specific 
interface requirements, and 5) application specific data and functionality specific to the 
types of business transactions being processed. 

With respect to claim 8, Ludwig teaches "a method for processing an 
electronic data record of an invoice, the electronic data record" as the system may 
allow data to be entered for the following exemplary fields, which the system may be 
adapted to store as global information on the database: name, address, city, state, zip, 
country, phone, number, fax number, and maximum invoice amount allowed. The 
system may use the maximum invoice amount allowed field to establish a threshold for 
a maximum payment for a single invoice (Ludwig Paragraph 0075) "comprising a 
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data field for identification of a current state of the processing of the invoice, the 
method comprising" as "Paid Through Another Source" may be provided by the 
system as an option for the biller system user to mark an invoice as closed by selecting 
desired invoices and clicking on the "Paid through another source" button. Once this 
occurs, the system may, for the invoices in question, update their audit trail to reflect 
that they were paid outside the system, and then change their status to closed (Ludwig 
Paragraph 0091 & 0130). Therefore the user is entering the state "closed" by clicking 
on the button. Therefore the identification of the current invoice is that it is paid and 
closed. 

Further, Ludwig teaches the filter area, the system may provide the following 
exemplary choices: by date (past due, eligible for discount, due within xxx days); and by 
status (paid invoices, adjusted invoices, unpaid invoices, paid through another source); 
and by payer (all payer, specific payer); and by attribute range between xxx and yyy 
(none, invoice numbers, store/location, purchase orders, purchase request number, 
invoice issue dates, dollar amount, bill of lading numbers, receiving location zipcodes, 
invoice aging) (Ludwig Paragraph 0080). These lines also teach the identification of 
the current state of the processing of the invoice. 

"displaying a dialogue on a display device for enabling the current state to 
be entered by a user and assigning the current sate entered by the user to the 
data field" as "Paid Through Another Source" may be provided by the system as an 
option for the biller system user to mark an invoice as closed by selecting desired 
invoices and clicking on the "Paid through another source" button. Once this occurs, 
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the system may, for the invoices in question, update their audit trail to reflect that they 
were paid outside the system, and then change their status to closed (Ludwig 
Paragraph 0091 & 0130). Therefore the user is entering the state "closed" by clicking 
on the button. Therefore the identification of the current invoice is that it is paid and 
closed. 

"wherein the data field has a link to the current state stored in a table" as 

the system may link the status field to the invoice history page, at which the system may 
display a full status history for the selected invoice. By default, the system may display 
the following exemplary columns: payer name, invoice number, due date, status, net 
amount due, amount to pay, P.O. number, P.O. requisition number, store number, and 
select (Ludwig Paragraph 0092). Therefore, these lines teach that the status field is 
being linked to the history page which contains the current status of an invoice. 

"a plurality of states of the processing of the invoice" as the perspective of 
the payer system user, the system may identify an invoice as having one of the 
following exemplary states: presented, viewed (an invoice may be considered "viewed" 
when a invoice display query is built with the invoice included; the user does not 
necessarily need to actually see the invoice to have it considered viewed), verified (an 
invoice that is in this state may be rolled back to viewed given the user has the 
permission to verify), payment initiated, payment authorized, payment pending (an 
invoice in this state may be rolled back to verified given the user has the permission to 
authorize payment), paid, and closed (Ludwig Paragraph 0127). 
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"an instruction which depend on the current state and are automatically 
executable by a computer system" as (Ludwig Paragraph 0091 and 0045). In 
paragraph 0045 email notices are being sent automatically based on the current state of 
the invoice. 

"starting a workflow which depends on the current state" as figures 6a-6c 
(Ludwig Figures 6a-6c). Figures 9a-9b teach a state dependent workflow for the 
payment of an invoice. Figure 7c teaches a state dependent workflow for adjustment of 
invoices. 

In figures 9a and 9b, the workflow for the payment is being initiated which is 
being dependent on the current state of the invoice, which is that the invoice is pending 
or due. 

Ludwig teaches the elements of claim 8 as noted above but does not explicitly 
discloses, "the current state stored in a state value table comprising a plurality of 
states of the processing of the invoice, and the state value table comprises an 
instruction which depend on the current state and are automatically executable 
by a computer system." 

However, Falk discloses, "the state value table comprises an instruction 
which depend on the current state and are automatically executable by a 
computer system," as the main purposes of the workflow table is to allow the system 
to determine the next workflow state for a transactional folder based on its current state 
and the completion of a given application function that alters that folder-i.e., the 
workflow state transition (Falk Paragraph 0589 and Figure 24). In addition to defining 
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workflow state transitions, the workflow table implicitly defines workflow navigation as 
well. For any given transactional folder in a given state, the workflow table will define 
the application functions that are allowed to be performed in this state (Falk Paragraph 
0591). Workflow state transitions are simple and deterministic-the next workflow state 
is determined simply by the current workflow state and the application function that was 
completed. However, in some cases, the transition can only be determined by 
inspecting other data elements within the transactional folder (Falk Paragraph 0603). 
Examiner interprets the workflow table as state value table comprising the current state. 
Workflow table/state value table further comprises executable functions that are allowed 
to be performed based on the current state. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teaching of the cited references because Falk's 
teaching would have allowed Ludwig to provide an automated system with the following 
capabilities unique to inter-organizational business transaction processing: 1) a 
centralized network hub (web-based) that facilitates the inter-connection of various 
organizations and eliminates the proliferation of point-to-point interfaces, 2) an inter- 
organizational workflow management system that provides a common framework for 
managing the state and status of all transactions within the system, 3) an inter- 
organizational transaction processing component that supports multiple organizations 
and their distinct relationship with each transaction while also ensuring the security and 
privacy of each organization's data, 4) a unified data model mechanism that allows 
common data elements to be exchanged while also supporting organization specific 
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interface requirements, and 5) application specific data and functionality specific to the 
types of business transactions being processed. 

Ludwig and Falk teach elements of claim 8 as noted above but do not explicitly 
teach "the current state stored in a state value table comprising a plurality of 
states of the processing of the invoice." 

However, Haseltine discloses "the current state stored in a state value table 
comprising a plurality of states of the processing of the invoice" as a status table 
may be generated for the bill to indicate the current status of the bill (Haseltine Col 3, 
Lines 41-43). Status tables 436 may also maintained in the active area 430 and may be 
viewed by customers. As the name implies, the status tables 436 track the status of the 
bills presented to the customers in the active area 430. For example, the status tables 
436 may track whether a customer's bills have been viewed, paid, have been submitted 
or are pending. Other indicia indicative of the status of the customers' bills may also be 
included in the status tables 436 (Haseltine Col 6, Lines 1 1-20 and figure 4). The table 
shows the current status of the invoice/bill and status table 436 shown in figure 4 shows 
plurality of processing states as well. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teaching of the cited references because 
Haseltine's teaching would have allowed Ludwig to allow customers to view and pay 
electronic bills in a flexible manner without the involvement of paper bill and checks. 
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With respect to claim 10, Ludwig teaches "the method of claim 8, further 
comprising: performing at least one of selecting, sorting, evaluating, and 
analyzing the electronic invoice according to the current state" as the system may 
provide a sort area to allow returned results to be sorted in ascending or descending 
order according to the following exemplary criteria: due date, invoice number, invoice 
date, purchase order number, net amount due, store or location number, and invoice 
aging (Ludwig Paragraph 0080). 

With respect to claim 12, Ludwig teaches "wherein the current state is 
selectable by the user according to predefinable events" as in this section, the 
system may permit biller system users to be associated with specific system events, 
which associations the system may be adapted to store as global information on the 
database. Any time one of these specific events occurs, the system may generate an 
automatic e-mail and send it to the selected list of biller system users. For example, 
exemplary distribution list choices may include: invoices loaded successfully, invoices 
loaded unsuccessfully, invoice adjusted, payment authorized, payment canceled, 
payment completed, and payment notification (Ludwig Paragraph 0104). The system 
may only permit invoices with the status of "paid", "presented", or "viewed" to be closed. 
All other invoice states may indicate payer workflow is in progress, and the system may 
not permit invoices having such states to be closed (Ludwig Paragraph 0105). 

The system may permit a biller system user to select an option 605 to display 
invoices based on selected criteria and/or specify general search criteria for listing 
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invoices. Depending on the selection, the system may direct the user to a "view 
options" page 606 for filtering and sorting (Ludwig Paragraph 0080). 

With respect to claim 13, Ludwig teaches "the method of claim 8, wherein the 
method is for use in business software, particularly in an enterprise resource 
planning software" as the business service provider system 16 may be an exchange 
or other service bureau application providing a plurality of business processing services 
to its clients (which may include the biller system 12 and/or payer system 14). One 
such business processing service may be electronic bill presentment and payment, as 
may be provided using a system and/or method consistent with the invention (Ludwig 
Paragraph 0027). 

Group of claims 14, 16, 18-19 and 20, 22, 24-25 are essentially the same as 
group of claims 8,10, and 1 2-1 3 except they set forth the claimed invention as system 
and a computer-readable medium comprising instructions and are rejected for the same 
reasons as applied hereinabove. 

With respect to claim 28, Ludwig teaches "an electronic data structure for an 
electronic data record according to any one of claims 1 and 3-7" as the exemplary 
embodiments of the system of the present invention described herein may be embodied 
as one or more distributed computer program processes, data structures (Ludwig 
Paragraph 0156). 
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Claim 29 is essentially the same as claim 13 except it sets forth the claimed 
invention as an electronic data structure and is rejected for the same reason as applied 
hereinabove. 

Response to Arguments 

3. Applicant's arguments have been considered but are moot in view of the new 
ground(s) of rejection. 

In these arguments applicant relies on the amended claims and not the original 

ones. 

See above rejections for response to the arguments. 

Claims must be given the broadest reasonable interpretation during examination 
and limitations appearing in the specification but not recited in the claim are not read 
into the claim (See M.P.E.P. 21 1 1 [R-l]). 

Ludwig teaches a billing system where a user/administrator marks an invoice as 
being closed once they are paid, and this done by clicking on a button by a user. Figure 
9 of Ludwig teaches a workflow for the payments which depends on the current state of 
an invoice being unpaid or overdue. Paragraph 0092 teaches that the status field is 
being linked to the history page, which contains the current status of an invoice e.g. net 
amount due, over due, paid etc. In paragraph 0045 email notices are being sent 
automatically based on the current state of the invoices. 
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Falk teaches the workflow table which examiner interprets as state value table 
comprising the current state. Workflow table/state value table further comprises 
executable functions that are allowed to be performed based on the current state. 

Haseltine's status tables show the current status of the invoice/bill and status 
table 436 shown in figure 4 shows plurality of processing states as well. 

Therefore the combination of these references provides the invention as a whole 
as claimed by applicant. 
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